「為什麼明明只是加個按鈕,卻搞了兩個禮拜?」
如果這句話讓你苦笑,那你來對地方了。今天我們要聊的不是技術,而是那些讓每個工程師都想翻桌的日常——那些我們不願承認,卻每天都在發生的開發困境。
身為一位軟體工程師,不論你是 Web 前端、後端,甚至是全端工程師,或是你是做 App 的工程師,一定都經歷過上線前還在 debug 的緊張時刻、上線後半夜被 On Call 叫醒要上 Hot Fix 的痛苦。那種在凌晨三點,眼睛盯著滿螢幕的 log,腦袋卻一片空白的感覺,我想你一定不陌生。
最崩潰的是什麼?是那種「明明在我的電腦上可以跑」的無力感。
你是否也經歷過每個 Sprint 的容量超出開發能量、或是 Sprint 中間有隕石砸下來,不得不用一些 Work Around 的方式去處理需求。然後下個專案,你發現自己又在寫一模一樣的東西,只是換了個名字、改了點參數。你開始懷疑:我到底是在創造價值,還是在當高級碼農?
這個狀況你或多或少都有遇過——當你以為一個 1 Point 的 User Story 你很快可以做完,而你確實也在一個下午做完了,但在 QA 階段或是 UAT 環節,發現需要調整,而變成無限長大的 User Story,或是一個簡單的 HotFix 最後卻變成一個 21 Point 的大功能。那種「早知道就不要說這很簡單」的懊悔,相信每個工程師都體會過。
這個場景你是否也十分熟悉:
早上 Standup Meeting,PM 說:「這個功能很簡單,就是加個按鈕。」兩週後,你還在處理各種 edge case、調整 responsive design、修復不預期的狀態管理問題。那個「簡單的按鈕」牽動了整個系統架構。
更諷刺的是什麼?你發現自己正在寫三個月前寫過的功能——另一個專案、另一個 client,但本質上是一樣的東西。你熟練地複製貼上,心裡想著:「我是工程師還是打字員?」
如果這些場景讓你心有戚戚焉,恭喜你,你不孤單。這就是我們傳統開發模式下的日常——不斷地重複、不斷地救火、不斷地懷疑人生。
我在職涯中待過不同的團隊,看過不同的開發流程,有使用看板、瀑布、敏捷開發的,有成功、也有失敗的。實話實說,這些開發流程都沒有好壞,但確實與團隊文化有非常大的關聯性。
而透過幾次失敗的經驗,筆者歸納出了一些開發流程中開發團隊容易遇到的核心問題,如下:
「Nico 離職了,現在沒人知道這個部署腳本怎麼運作。」
這句話在每個團隊都上演過。我們花了無數時間累積的 domain knowledge,隨著人員流動不斷流失。新人加入時,你試圖解釋系統架構,但發現連你自己都記不清當初為什麼這樣設計。
需求文件?別鬧了,能有任務的卡片留著就已經很不錯了,有時說不定 PM 都不記得功能的全部樣貌。通常你也不會期望註解就能說明清楚當初的開發背景跟需求脈絡。
真實案例:曾經某位同事非常不喜歡寫文件,在需求文件也沒有的情況下,根本也沒有人看得懂他寫的程式為什麼要這麼做。最後他離職時,我們花了整整一個月才搞懂他負責的支付模組邏輯。
知識管理不是技術問題,是人性問題——我們總是高估自己的記憶力,低估知識傳承的重要性。
需求是怎麼變形的?讓我們追蹤一個功能的誕生:
每一次轉譯都是一次失真。更糟的是,這些溝通佔據了我們大量時間:
算算看,一個兩週的 Sprint,光是會議就佔了 20+ 小時。而真正寫 code 的時間?可能不到一半。
筆者最長的 Sprint Planning 開會時間是可以開到一天的(PO 解釋需求、團隊估點、Task Break Down),而且這還不是最終的需求確認,需求經由討論設計都還可能持續變動。
統計一下你的職業生涯,有多少時間花在:
這些不是創造性工作,是機械性勞動。但因為每個專案「稍微有點不同」,我們無法真正重用。於是陷入了「複製-貼上-修改」的無限循環。
一位資深工程師的自嘲:「我寫了十年程式,其中五年在寫 for 迴圈,三年在處理 null pointer,剩下兩年在 Google 怎麼垂直置中。」
即便是筆者很崇尚 Clean Code 的精神,也不免還是需要很多重複的工作。光是 Terraform 在沒有模組化的時候,你就有可能一直重複再重複地寫相同的 resource 定義。
「這個先 hardcode,之後再改。」——每個工程師都說過的謊言。
技術債是這樣累積的:
真實統計:一個五年的專案,平均有 40% 的程式碼是技術債。維護這些程式碼的成本,是開發新功能的 3-4 倍。
但為什麼我們還是不斷累積技術債?因為 PM 永遠在問「什麼時候可以上線」,而不是「程式碼品質如何」。
理想很豐滿,現實很骨感。我們工程師都很想要自己維護的專案是漂亮的,至少都遵循了 SOLID 或是 Clean Code 的精神,但現實的隕石跟十分著急的 PM 以及憤怒的老闆通常不會在乎我們的程式有多麼漂亮,畢竟漂亮的程式碼的價值可能只有我們知道而已。
早上 9 點,你充滿活力,一小時寫了 200 行高品質程式碼。
下午 3 點,你盯著螢幕發呆,一個簡單的 function 想了半小時。
晚上 7 點,你開始懷疑自己是不是該轉行。
人類的認知能力有限。研究顯示,程式設計師一天真正高效的時間只有 2-4 小時。剩下的時間在:
我們試圖用各種方法提升效率:番茄鐘、GTD、時間管理...但本質問題沒變:我們在用石器時代的大腦,處理太空時代的複雜度。
筆者已經習慣同時寫程式、開會、部署的生活,半夜的時候還可以讓夢中的自己去設計明天預計完成功能的架構。但這樣的「效率」,其實是在透支未來的生產力。
討厭那麼麻煩的團隊流程嗎?我們有時候會想,有時候想單純地寫程式做產品,到最後都在花時間 build team。但是如果你是團隊開發者,至少還有人可以討論、分工。
但個人開發者?你要同時是面對一些挑戰。
即便你擁有所有領域的能力,你也沒有那麼多時間。時間是最公平的資源,每個人一天都只有 24 小時。
每個決定都要自己做,沒有人討論,沒有人 review。做對了沒人誇,做錯了沒人救。
最諷刺的是,市場上充斥著「一個人做出獨角獸」的故事,彷彿你的失敗只是因為不夠努力。但現實是:一個人的力量,在現今的技術複雜度面前,真的太渺小了。
讀到這裡,你可能會問:既然問題這麼明顯,為什麼我們還是無法解決?
答案很殘酷:因為這些不只是技術問題,更是系統性問題。
更深層的原因是,我們一直在用「管理」的思維解決「工具」的問題。敏捷、Scrum、看板...這些都是在優化流程,但寫程式的本質困難並沒有改變。
就像你不能期待跑得更快的馬車能夠競爭過汽車,我們需要的不是更好的流程,而是革命性的工具。
好消息是,這個工具已經出現了——AI 輔助開發。它不是另一個框架,不是另一個方法論,而是真正能夠理解你、協助你、放大你能力的夥伴。從 GitHub Copilot 到 Claude,從 Cursor 到 Kiro,AI 正在改變開發的本質。
下一篇,我們將深入探討為什麼連敏捷開發都無法解決這些根本問題,以及新的曙光在哪裡。
在那之前,我想問問你:上述的問題中,哪一個最讓你痛苦? 歡迎在留言區分享你的故事。
記住,承認問題是解決問題的第一步。而我們,正站在改變的起點。